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(57) Abstract 



A computer network node (500) for a financial trading network, comprising a database (547) capable of storing trade data and a 
network interface (508) for connecting to a computer network. The computer network node includes a unique node identifier, an inbound 
trade processor (520) connected to the network interface (508) for receiving an inbound trade message and extracting inbound trade data and 
an outbound trade processor (533) for creating an outbound trade message and inserting a trade message into an appropriate communications 
protocol. The computer network node further includes a database processor (539) for controlling outputs from trades database (547) and 
creating and sending outbound trade data to the outbound trade data processor (533). Finally, the computer network node includes a 
background processor (529) connected to the trades database (547) and the network interface (508) for reconciling an ownership transfer 
message with an ownership status contained in the database. 
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COMPUTER NETWORK NODE FOR A FINANCIAL TRADING NETWORK 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates generally to a financial 
trading network, and more particularly to a computer network 
node and node processes for implementing a financial trading 
network . 

2. Description of the Background Art 
Financial trade activities are a common and often 

performed method of transacting business. There may be 
activities for buying or selling stocks, bonds, commodities, 
conducting banking activities, credit transactions, etc. 
Trade activities frequently are conducted at a distance, with 
no actual transfer of property or currency actually taking 
place, and commonly occur with only the transfer of data. 
Trade activities conducted by only a data transfer can easily 
be performed by electronic means. There are many advantages 
to electronically conducted data trade activities, such as, 
for example, speed, convenience, lesser risk of theft, loss, 
or wasting, and the ability to transmit an electronic trade 
activity to any location on the globe. 

Electronic trade activities conducted over a computer or 
digital data network are not hampered by the size or location 
of the transaction, and increasingly occur across 
international borders. Electronic networks also offer other 
advantages, such as, for example, the ability to transfer 
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other data along with a trade activity, ability to transfer 
ownership, ability to add or modify other status types, 
ability to transmit status requests, ability to track 
information or trade activities, etc. 

- With the advent of digital networks, such as the * 
Internet, trading networks have rapidly grown in size and use 
due to the advantages listed above. Typically, trading 
networks were designed for existing communications protocols 
and existing network hardware and software. Data could be 
transmitted between different nodes in such a network (a 
"node" being any computer or device on the network) , but often 
a gateway or translator was needed to connect each node to the 
network . 

Electronic trade activities have in the past been 
designed for specific network systems. Typically, small 
systems were set up for a small task that was later outgrown. 
Smaller systems were therefore often combined to form larger 
systems/ Various computers, network hardware, and software 
were often combined in a single system or across communicating 
systems . 

Several disadvantages exist in prior art networks and 
network nodes. First, the use of various network node 
software produced transactions that differed in content, 
organization, data storage protocols, and data transfer 
procedures. Second, the use of various communications 
protocols also produced systems having trading activities 
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where the sending node and the receiving node were operating 

in a different manner. Third, networks were not designed and 

constructed with uniform application and future expandability 

in mind. 

•' Earlier remedies to these disadvantages have been 
attempted, such as a gateway between a node and the network, 
where the gateway can translate a trade activity between any 
number of communications protocols and data arrangements. A 
gateway does not eliminate, however, the multiple 
communication protocols, and must accommodate all data 
arrangements that may possibly be received. In addition, a 
gateway requires additional processing time, and may cause a 
slowdown in data traffic- 
Organizations planning to regroup their support 
operations have also implemented a "hub and spoke" 
architecture in which a central support site (or hub) is 
dedicated to processing trades for a number of outposts (or 
spokes) / This approach, however, also has its limitations, 
the main drawback being that a bank may find itself locked 
into a rigid structure that proves difficult to adapt as 
business changes. If all trade information has been designed 
to flow between front and back offices, what happens when the 
bank decides to introduce a new function, such as global 
credit control, at one of its locations? In a hub and spoke 
scheme, providing the credit controller with essential and 
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correct trade details may involve major alterations to the 
underlying technology . 

What is needed therefore is a financial trading network 
having a standard computer- network node and node processes for 
performing trade activities. 



SUMMARY OF THE INVENTION 
A computer network node for a financial trading network 
is provided according to a first aspect of the invention. The 
network node includes a database capable of storing trade 
data, a network interface for connecting the network node to a 
computer network over which a trade message may be transmitted 
or received, a unique node identifier for the network node, an 
inbound trade processor connected to the network interface, 
with the inbound trade processor capable of receiving an 
in'bound trade message and capable of extracting inbound trade 
data included in the trade message, an outbound trade 
processor* connected to the network interface, with the 
outbound trade processor capable of creating an outbound trade 
message and capable of inserting a trade message into an 
appropriate network communications protocol including a 
financial trading network communications protocol and the node 
identifier and communicating the outbound trade message to the 
network interface, a database processor for controlling 
outputs from the database and capable of creating and sending 
an outbound trade message to the outbound trade processor, a 
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background processor connected to the database and connected 
to the network interface, and capable of sending and receiving 
an ownership transfer message and reconciling the ownership 
transfer message with an ownership status contained in the 
database. The trade data in a trade message is organized by 
unique fields, including common data fields, product specific 
data fields, macro specific data fields, settlement 
instruction data fields, and audit data fields. These fields 
can include active trade -activity data or static local data. 

A financial trading network node process for receiving 
inbound trade messages (said trade messages including active 
trade activity data and/or static local data) over a computer 
network is provided according to a second aspect of the 
invention. The financial trading network node process 
includes the steps of receiving an inbound trade message over 
a network at a first node, removing a financial trading 
network communications protocol from the inbound trade 
message', storing the trade data contained in the inbound trade 
message in a database, and sending an acknowledge message 
corresponding to receipt of the inbound trade message. 

A financial trading network node process for generating 
outbound trade messages (said trade messages including active 
trade activity data and/or static local datd) over a computer 
network is provided according to a third aspect of the 
invention. The financial* trading network node process 
includes the steps of receiving in a first financial trading 
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network node a signal to transmit a trade message to a second 
financial trading network node, creating a trade message by 
obtaining the trade data from a database in the first 
financial trading network node, retrieving a target node 
location from a node location database and placing the target 
node location in the trade message,- inserting the trade 
message into a financial trading network communications 
protocol, inserting the trade message and the financial 
trading network communications protocol into a network 
communications protocol, transmitting a message including the 
trade message, the financial trading network communications 
protocol, and the network communications protocol over the 
computer network, and receiving an acknowledge message 
corresponding to transmission of the trade message. 

An ownership transfer process for arbitrating trade 
ownership messages over a computer network is provided 
according to a fourth aspect of the invention. The ownership 
transfer process includes the steps of: 1) sending an 
ownership transfer request message from a requestor node to 
the owning node; 2) determining whether the ownership transfer 
request message was received by the owning node; 3) if the 
transfer request message was received by the owning node, 
determining whether the ownership transfer request can be 
granted, and sending an ownership granted message to the 
requestor node if the request can be granted, and sending an 
ownership denied message to the requestor node if the request 
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cannot be granted; 4) if the transfer request message was not 

received by the owning node, determining if the owning node 
crashed and redelivering the ownership transfer request 
message to the owning node if the ownership transfer request 
was -hot received by the owning node and the owning node had 
crashed; 5) manually resending the ownership transfer request 
message if the ownership transfer request was not received by 
the owning node and the owning node did not crash; and 6) 
sending a second ownership transfer message from the owning 
node to the requester node if a second ownership transfer 
request message is received by the owning node before the 
ownership transfer message is sent by the owning node. The 
trade ownership process of the present invention eliminates 
the dependencies of the financial trading nodes on each other 
( i.e. , there is no central resource) , thereby improving 
usability and efficiency of the financial trading network. 

The present invention thus provides an electronic 
environment enabling all types of financial trades globally 
and at maximum operating efficiency and effectiveness. The 
above and other features and advantages of the present 
invention will be further understood from the following 
description of the preferred embodiments thereof, taken in 
conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 shows a simplified network configuration; 
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Fig. 2 shows an overview of a financial trading network 
in accordance with the invention; 

Figs. 3A-3B show exemplary trade entry screens that may 
be used for creating a trade activity message; 

Figs. 4A-4B show a. general data organization of a 
financial trading network communications message of the 
present invention ; 

Fig. 5 shows a block diagram of a financial trading 
network node of the present invention; 

Fig. 6 shows representative trade ownership transfers; 

Fig. 7A-7D show representative display screens available 
through a network node of the present invention; 

Fig. 8 shows a flowchart illustrating an inbound trade 
activity message receiving process in accordance with the 
present invention; 

Fig. 9 shows a flowchart illustrating an outbound trade 
activity message transmitting process in accordance with the 
present invention; and 

Fig. 10 shows a flowchart illustrating a representative 
trade ownership transfer method in accordance with the present 
invention . 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
Trade activity may be generated in a number of ways. 
Generally, trade activity may be any form of financial or 
business transaction. For purposes of this description, trade 

8 
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activity is defined as any trade activity taking place over an 

electronic network such as a computer network, for example the 

Internet. Many other applicable networks exist, such as an 

intranet, local area networks (LANs) , wide area networks 

(WANs) , etc. 

Trade activities are generally originated at a front 
office, where a trade activity may be initiated by a purchase, 
sale, or other transaction. After being generated, a trade 
activity may be transmitted to a financial trading network 
node (if the front office trade activity generator is not a 
network node), or transmitted to other nodes. During the life 
of the transaction, the trade activity may be passed between 
nodes and may change ownership multiple times. 

Examples of trade activities that may be accommodated by 
the present invention are money market transactions, 
derivative transactions, securities transactions, bullion 
transactions, and foreign exchange transactions. Money market 
transactions may include deposits, rollovers/renewals, 
fiduciary deposits, call and notice deposits, complex 
deposits, structured deals, certificates of deposit (CDs) , 
BAs, commercial paper, and treasury bills. Derivative 
transactions may include futures, OTC options, exchange 
options, FRAs, FXAs, interest rate swaps, and caps, collars 
and floors. Securities transactions may include equities, 
fixed income, private loans, custody, borrowing/lending, 
repo's/reverses, floating rate notes, and mortgaged backed 
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securities/CMOs . Bullion rransactions may include purchases, 
sales, arbitrage (physicals and futures) , loans, consignments, 
depository balances and transfers, and custody processing. 
Foreign exchange transactions may include spot exchanges, 
outright exchanges, and swap exchanges. 

Fig. 1 shows a typical electronic network 100, having a 
communications link 110 extending between a plurality of 
computers or devices 120, 130, 140, and 150. Each of the 
computers 120-150 can send and receive data over the 
communications link 110. This is a simplified example of a 
network. In reality, computer networks possess many complex 
and often troublesome features that may hamper data 
transactions. First, the communications link 110 may be 
composed of multiple segments, such as telephone lines, fiber 
optic cables, dedicated data lines, etc. Therefore, each 
segment may have its own characteristics, and potentially may 
have individual data transmission protocols governing the data 
format. 'Second, each device connected to the communications 
link 110, such as the computers 120-150, may each have a 
distinct internal data format and may be using any one of a 
multitude of network connectivity mechanisms. As a result, 
communications between individual computers or nodes (any 
computer or device on the network) is not always successful. 
These variations in network hardware and software may lead to 
failures to establish communication, loss of established 
communication, erratic communication (including slow 
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communication), loss of data, etc. Ideally, all computers and 
devices in a network should be able to communicate without 
errors, but in reality the large variety of hardware and 
software types mean that no singular standard governs 
electronic data transmission, and as a result errors may 
occur. 

Data communications standards and protocols exist and are 
widely used. Examples are Transmission Control 
Protocol/Internet Protocol (TCP/IP) , Internet Protocol (IP) , 
UDP/IP Protocol, Fiber Channel, X.25, Frame Relay, etc. While 
these protocols generally ensure reliable data communications, 
they are typically employed in conjunction with a wide variety 
of data-generating software. The data therefore may not be in 
a format usable by both the sending and receiving devices. 
The present invention addresses this problem by providing a 
financial trading network node having standardized software. 
The financial trading network node software of the present 
invention operates each node in an identical fashion, thereby 
eliminating the differences in data at the sending and 
receiving devices. The financial trading network 
communications protocol thus ensures that data sent between 
nodes conforms to a known and expected form. This is a need 
and purpose behind the present invention. 

Fig. 2 shows an embodiment of a financial trading network 
of the present invention employing a general network 155. The 
financial trading network of the present invention is a 
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plurality of nodes 163 on the general network 155 that 
communicate to accomplish a task or tasks. 

The financial trading network of this invention allows a 
trade to be modified in multiple locations ( e.g. , by several 
different network nodes) , without causing or creating multiple 
versions of the trade. As is described in more detail below, 
this trade modification is achieved by using the concept of 
trade ownership ( i.e. , a node "owns" a trade) . Thus, the 
present invention permits a trade activity to be created at a 
Singapore node 161, and subsequently transferred to a London 
node 164 for further processing (London and Singapore are 
examples, and not necessarily actual nodes); or a static local 
data activity to be created at the Singapore node 161, 
transferred to and stored in a node designated as the 
centralized static data repository node 166, and later 
transferred to a compliance and audit node 169 for audit 
processing - all with efficiency and accuracy. Thus different 
function^ are permitted to be seamlessly split across 
locations and time zones, and scaled to meet each location's 
business requirements . 

In short, the present invention, therefore, permits each 
trading support site to publish and subscribe to the 
information it needs to fulfill its role, whatever that role 
may be. When a sales desk publishes a trade, for example, 
several sites (nodes) can be listening out for the trade 



12 



nocm- <wo 



O0<Sft890A1 I > 



* WO 00/58890 PCT/US00/07739 

details, each with a different task to perform after acquiring 
"ownership" of the trade. 

A typical computer network, such as the Internet, for 
example, has what is called a stratified architecture. A 
typical network architecture employs, for example, a TtP/IP 
message communications protocol ha'ving multiple transport 
layers. The TCP/IP protocol is designed to transmit data 
across packet-switched networks. In order to prevent large 
messages from unnecessarily congesting packet networks, 
messages are broken into multiple small pieces, called 
packets, transmitted across the network, and then re-assembled 
at the destination. A packet is a block of data that contains 
within it the necessary addressing and transmission 
information so that the message data can be delivered to a 
desired destination. A packet-switched network uses the 
addressing information to switch the packet from network to 
network as the packet moves toward its destination. 

According to a preferred embodiment of the invention, the 
message data and therefore the user-generated data layer are 
) formed substantially of a financial trading network deal 

record. A trade deal record will consist of all the details 
concerning the trade (trade data) . This trade data is used to 
form a trade message. Figs. 3A and 3B show representative 
trade entry screens that may be used to enter data to form a 
5 trade message. 
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A trade message that is sent between nodes contains the 
data that exactly describe the transaction. The trade data 
which forms the trade message can include both active 
(dynamic) trade activity data and/or static local data. In 
creating a trade message to be used in the network node^ 
processes of the present invention,- the active trade activity 
data is obtained from a trade database in a node, whereas the 
static data is obtained from a local (or supporting) database 
in the node. 

The trade data which forms the trade message is organized 
into unique fields - these can include trade activity fields 
and/or static data fields. The fields are grouped in several 
different categories; some of the overall categories are (but 
not limited to) Common Data, Product Specific, Macro Specific, 
Settlement Instruction, and Audit fields. The Common Data 
category contains fields common to all products, for example, 
System Number, Counterparty and Dealer. The Product Specific 
category 'includes fields unique to a product, for example, the 
Principal field is a field in this category for a Spot trade, 
but not for a Deposit. The Macro Specific category includes 
fields unique to a linked group of trades, such as Contract 
Number, FOMAC CCY1, and FOMAC CCY1 to CCY2 Spot rate. The 
Settlement Instruction category comprises one or more groups 
of fields that identifies what to when the trade settles, 
e.g. , PAY TO Location, PAY FROM Location, REC AT Location. 
The audit fields category is used to trace changes to the 
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trade, and contains fields such as Created By, Enriched By, 
Released By and Activity Indicator. 

Some examples of trade activity fields (comprising act 
trade activity data) are: 



Common Data 

System Number 

Counterparty 

Dealer 
Product Specific 

Principal 

Quantity 
Macro Specific 

Contract Number 

FOMAC CCY1 

FUMAC CCY1 to CCY2 Spot rate 
Settlement Instruction 
PAY to location 
PAY from location 
REC at location 

Audit 

Created by 
Enriched by 
Released by 
Activity indicator 



NA123456 

CHASE/NYC 

PERSONA 

25,000, 000.00 
10, 000 

RT-00001281 

DEM 

2.341 

CHASE/LDN 
BARCLAYS /LDN 
BARCLAYS /NYC 

PERSONB 
PERSONC 
PERSOND 
9 



Some examples of static data fields are: 
INSTRUMENT - TYPE FX 
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INSTRUMENT - CODE CAD 

INSTRUMENT - DESCRIPTION Canadian Dollars 

INSTRUMENT - SF - SHIFT - DECIMAL 2 

Example data fields for a particular Spot type trade, one 
of the many product types supported by the present invehtion, 
could include: Trade Date, Instrument, Value Date, Trade Rate, 
and System Number (a unique number assigned to each trade) . 
It should be understood that the data fields may be deleted 
from or added to as necessary, and the data may change as 
needed . 

In a preferred embodiment of the present invention, the 
TCP/IP and UDP/IP communications protocols are employed, but 
alternatively other communications protocols such as SNA, X.25 
or Frame Relay may be used. The data layer employs the 
FINANCIAL TRADING NETWORK™ communications protocol available 
from OMR Systems Corporation, Skillman, New Jersey 08558. The 
modular architecture of the financial trading network 
processes; however, allows use of any third party middleware 
software which can provide a reliable transport mechanism over 
a standard TCP/IP interface with minimum modifications. 

Fig. 4A illustrates a general data organization of a 
financial trading network communications message. The 
financial trading network communications message has a header 
410 and a message body 420. The header 410 contains a message 
length field (the length of the complete message) , a message 
type field, a data buffer length field (size of the trade 
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data), and an acknowledgment (ACK) buffer length field. The 
message body 420 contains the trade data that is being 
transmitted. The data arrangement of the header 410 will be 
recognized by any financial trading network node on the 
financial trading network. The financial trading network 
communication message therefore allows each node to receive 
data in an expected form. 

Fig. 4B illustrates a general data organization of a 
financial trading network acknowledgment (ACK) message. The 
ACK message is used to acknowledge the receipt of a trade 
message. The ACK message therefore insures communications, 
reliability by finalizing a communications transaction. The 
ACK message contains an ACK message header 4 60 and an ACK 
record buffer 470. The ACK message header 460 contains an ACK 
message length field, an ACK message type field, and an ACK 
length field. 

Fig. 5 shows a financial trading network node 500 of the 
present invention. As indicated above, the financial trading 
network nodes of this invention perform inbound and outbound 
processing on both active trade activity data and static local 
data. For simplicity of description, the network node of Fig. 
5 shows the inbound and outbound processing elements in terms 
of processing active trade activity data. The invention is, 
however, not limited to processing active trade activity data, 
but also includes the node 1 s separate processing of static 
local data. The interconnection and processing steps 
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described below in terms of trade activity data processing are 
substantially the same for static local data processing and 
should be viewed in that context. 

The computer network node 500 of Fig. 5 includes a 
network interface 508, a network monitor 511, a message^ 
activity file 514, an inbound trade activity processor 520, an 
event flag 525, a background processor 529, an outbound trade 
activity processor 533, a checkpoint file 536, a trades 
database processor 539, a node identifier 541, an 
authorization file 544, a trades database 547, a trades 
ownership database 552, a nodes location database 556 and a 
collision queue 557. (It can be seen that if the node of Fig. 
5 was processing static local data, the inbound and outbound 
processors (520, 533) would be termed inbound and outbound 
static local data processors; and trade database 541 would 
instead be a local database accessed by a local database 
processor . ) 

In Figure 5, the network interface 508 is connected to a 
network 503. The network 503 may be a TCP/IP based network or 
any type of general purpose network, such as, for example, the 
Internet, a telephone line, an intranet, a local area network 
(LAN), a wide area network (WAN), etc. The network monitor 
511 is connected to the network interface 508, and is further 
connected to the message activity log 514. Message activity 
log 514 is also connected to background processor 529 and will 
contain information about the trade activity over the 
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financial trading network and the relevant protocol 

information. Inbound trade activity processor 520 is 

connected to network interface 508, outbound/inbound state 

527, and trades database processor 539. Inbound trade 

activity processor 520. is also connected to event flag* 525 

(connection not shown), to the extent that said processor 

thereby receives a signal instructing a shut down. Background 

processor 529 is connected to network interface 508 and is 

further connected to outbound/inbound state 527 and trades 

database 547'. The outbound trade activity processor 533 is 

connected to network interface 508 and is further connected to 

checkpoint file 536, trades database processor 539, event flag 

525 and message activity log 514. The trades database 

processor 539 is further connected to the node identifier 541, 

authorization file 544, trades database 547, and event flag 

5*25. The trades database 547 includes trades ownership 

database 552 and nodes location database 556. 

The trades database 547 stores all trade activity 
information for each trade activity message received by the 
node and each trade activity owned by the node. In addition, 
the trades database 547 in one embodiment includes the nodes 
location database 556 and the trades ownership database 552, 
but alternatively the nodes location database 556 and the 
trades ownership database 552 may be separate databases. 

The nodes location database 556 contains node identifiers 
of substantially all of the other nodes in the financial 
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trading network, and provides a node location as needed when 
generating or receiving a trade activity message. 

The trades ownership database 552 may be used to store 
the ownership status of any trade activity that the node has 
participated in. The trades ownership database 552 may be 
used to obtain the next owner of any trade activity during 
processing . 

The network interface 508 connects to the network 503 and 
transmits and receives messages therefrom. In the preferred 
embodiment, the network interface 508 is a hardware/software 
combination that is capable of autonomously handling network 
communications over a computer network employing, for example, 
a TCP/IP network communications protocol. In an alternate 
embodiment, an external network interface may be employed. 

The message activity 'log 514 contains a log of all 
messages sent or received by a network node as well as updated 
acknowledgment information for each transmission of a message. 
The message activity log 514 may be used to investigate 
transmission errors, to manually resend a transmission if the 
transmission was not successful, to audit message traffic or 
trade activity, or to create a paper record of all 
transactions occurring on the network node 500. 

The network monitor 511 monitors all inbound and outbound 
message traffic of the network node 500 and can request 
statistics from any node on the logical financial trading 
network. The network monitor 511, when used in conjunction 

20 



mr.in- /wn 



OMO ~ - ~ ~ OO 



WO 00/58890 PCT/US00/07739 
with a display device, such as, for example, a computer 

monitor, can display global views of all network nodes or 

specific views of individual network nodes. The network 

monitor may display, for example, information in the form of 

text, tables, graphs, maps, etc. 

The inbound trade activity processor 520 receives trade 
activity messages from the network interface 508, removes the 
financial trading network communications protocol, and passes 
the trade activity data to the trades database processor 539. 
To complete the inbound trade activity message transaction, 
the acknowledgment message is returned to the sender. 

The outbound trade activity processor 533, in response to 
an activity event flag signal (which in the preferred 
embodiment is asynchronous) , receives trade activity 
information from the trades database processor 539 and 
prepares an outbound trade activity message containing the 
trade activity information. The outbound trade activity 
processor 533 determines whether an acknowledgment message has 
been received and puts a copy of each outbound trade activity 
message into message activity log 514 and updates message 
activity log 514 with respect to whether an acknowledgment 
message was received. The outbound trade activity processor 
533 also puts the latest successfully processed trade 
information into the checkpoint file 536. The checkpoint file 
536 therefore contains the information about the last 
successfully processed deal by the outbound trade activity 
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processor 533. The checkpoint file 536 may be used by the 
network node 500 for configuration purposes during system 
startup or for crash recovery. It should be recognized that 
although the above processes are described as event-driven, 
the invention also contemplates real-time operation, including 
both event-driven and batch-driven -operation. 

The trades database processor 539 regulates all trade 
activities entering or leaving the network node 500. The 
trades database processor 539 receives inbound trade activity 
messages from the inbound trade activity processor 520, 
compares the node identifier in the received message to the 
nodes location database 556 to identify the source of the 
message, and stores the associated trade activity data in the 
trades database 547. The trades database processor 539 may 
access the collision queue 557 to check whether a collision 
has occurred or transaction may be performed. 

The authorization file 544 regulates where a trade 
activity 'will be performed (on which nodes), for which 
products it will be performed ( i.e. , which type of trading 
instrument such as spot, deposit, security, bullion, interest 
rate swap, etc.), and for which customers or clients it will 
be performed. Each network node 500 will have an 
authorization file 544. 

The trades database processor 539 may generate an 
outbound message in response to several events (the inbound 
trade activity processor 520 having produced the message to be 
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sent as a data response to a received message) . These events 
can include a manual input by an operator, an internal 
condition such as a need for information from another node, or 
an ownership transfer need. 

• "' When the trades database processor 539 is required to 
send a trade activity message, the trade activity data is 
retrieved from the trades database 547 and passed to the 
outbound trade activity processor 533. The node identifier 
541 is also communicated to the outbound trade activity 
processor 533. 

The background processor 529 has several functions. 
First, the background processor 529 oversees ownership 
transfers between nodes. Second, the background processor 529 
generates and transmits node statistics for the network node 
500. The statistics may be sent to a specific node or all 
nodes, and may be sent periodically or on demand. Such 
statistics may include, for example, information concerning 
which nodes are currently online and functioning, traffic 
levels, etc. The background processor 529 also oversees trade 
ownership and trade ownership transfers. 

The network node 500 as described above implements a 
uniform and scalable financial trading network that 
facilitates robust operations and allows for' easy expansion. 
The network node 500 also allows the use of industry standard 
software elements. This may be accomplished without the need 
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for hardware to be uniform within the financial trading 
network . 

One standard software application that may be used in a 
network node 500 is the TRADING ASSISTANT® software, which 
performs a variety of trade activity functions. The TRADING 
ASSISTANT® is available from OMR Systems Corporation, 
Skillman, New Jersey, 08558. 

Representative trade activity functions performed by 
TRADING ASSISTANT® include, for example, trade processing, 
deal control, accounting interface, advice control, balance 
updates, cash flow control, corporate action control, static 
database updates, data feeds, pre end-of-day, daily 
operations, and file maintenance. Representative trade 
processing functions include add, enrich, release, 
Change/cancel, confirm match, inquire, swap unwind, close 
fails, exercise/assign options, renew deposits, input FRA/FXA 
fixings, CNT revision, and phone confirmation operations. 
Representative deal control functions include deal receiver, 
trade generation, and auto-trade release operations. 
Representative accounting interface functions include UI and 
live UI operations. Representative advice control functions 
include auto, custom interface, fax, mail, S.W.I.F.T. messages 
(developed by Society for Worldwide Interbank Financial 
Telecommunications S.C., Belgium), and Telex operations. 
Representative balance update functions include FX, Nosrro, 
currency, position, and securities operations. Representative 
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cash flow control functions include cash flow generation and 
rate settings and log operations. Representative data feed 
functions include corporate action events and customer 
information operations. Representative pre end-of-day 
functions include pre end-of-day validation, specify purge 
criteria, and restore to before pre end-of-day operations. 
Representative daily operations functions include pre new day, 
new day, and end of day operations. Representative file 
maintenance operations include restore to before new day, 
restore to before last end-of-day, purges and condenses, and 
recreation of balance records operations. 

Other features may be incorporated into each network node 
500, such as, for example, data encryption, certified message 
delivery, etc. 

Fig. 6 illustrates trade ownership transfers. The first 
ownership transfer 610 is a single ownership transfer request, 
including an ownership transfer request and a granting of 
ownership by the current owner. The second ownership transfer 
620 shows how^ multiple ownership requests receive multiple 
acknowledgments. The third ownership transfer 630 shows an 
automatic recovery process conducted when the ownership 
request is not successfully completed. The fourth ownership 
transfer 640 shows a manual recovery process conducted when 
the ownership request is not successfully completed. The 
fourth ownership transfer 640 includes a manually resent 



25 



WO 00/58890 PCT/US00/07739 

ownership request that is prompted by a lack of response zo 
the original ownership transfer request. 

In the present invention, as mentioned above, a trade may 
be modified by several different financial trading network 
nodes'. This is referred to as distributed trade modification. 
The distributed trade modification 'is achieved by using the 
concept of trade ownership (discussed further in conjunction 
with Fig. 10 below). A trade can only be changed on the 
financial trading network node that owns it. If another node 
wants to change a trade, it must first become the owner. To 
get trade ownership, a request must be made to the node that 
owns the trade. The request will either be granted or denied. 
Once a node becomes the owner, the trade is then changed and 
the trade activity processor 533 updates the other nodes. The 
request will be denied if 'either the owning node is 
unreachable or the owning node has already transferred 
ownership to another node. Only two nodes participate in the 
ownership transferal process. This reduces the dependencies 
of nodes on each other (no centralized resource) and improves 
the usability of the system. 

The modification of trades is optimized by automatically 
transferring trade ownership during trade processing. In a 
preferred embodiment, network nodes are configured to perform 
specific business functions. For instance, a first node may 
add trades while a second node may enrich and release trades. 
The trades database processor 539 of a node determines which 
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node is the next trade owner by using ownership database 552. 
Therefore, when a first node adds a trade, a second node may 
automatically- become the owning node. This streamlines 
processing because the majority of modifications will occur on 
the 'node with trade ownership. Only the exceptions to this 
scheme will require ownership transferal. 

Fig. 7A shows a global map monitor screen feature of the 
network monitor 511, illustrating a network nodes display for 
the financial trading network. Fig. 7B shows a nodes 
statistics monitor screen feature of the network monitor 511, 
illustrating an operating statistics display for the financial 
trading network. Fig. 7C shows a local node statistics screen 
feature in bar graph form, illustrating another embodiment of 
the operating statistics display. Fig. 7D shows a tabular 
data embodiment of the operating statistics display. 

Fig. 8 shows a flowchart 800 of the present invention 
illustrating a trade activity message receiving process. 
(Again, 'for simplicity of description this inbound message 
processing is described in terms of active trade activity data 
in a trade message; however, essentially the same process is 
also performed on static local data contained in trade 
messages, employing a local database and database processor.) 
In step 810, the method determines whether a trade activity 
message has been received. If a trade activity message has 
been received, the method proceeds to step 820, else it 
branches back to step 810 until a message is received. 
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In step 820, network communications headers are removed 

from the inbound trade activity message. Although this is 
shown as a step in the inbound process, it should be . 
understood that removal is- automatically performed by a 
network communications handler. In the present invention, 
this may be accomplished by the network interface 508 (Fig. 5) 
or alternatively by a separate hardware / software combination 
external to the financial trading network node 500. 

In step 830, the financial trading network message header 
is removed from the inbound trade activity message. 

In step 840, the trade activity contained within the 
trade activity message is stored in the trades database 547. 

In step 850, an acknowledgment message is transmitted to 
the financial trading network node that sent the trade 
activity message. The acknowledgment message informs the 
sending node that the message was properly received. If the 
sending node does not receive an acknowledgment message, the 
sending node may optionally resend the original message or log 
an error. In addition, an operator may manually resend the 
message . 

A further feature of the trade activity message receiving 
process of Fig. 8 is a collision detection capability (not 
shown) . Collisions are defined as changes to data applied out 
of sequence. In order to guarantee correctness of the trade 
database on each network node, all updates to trades must be 
applied in the same progression. There are situations that 
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will occur, for example, due to network latency between nodes, 
which can cause the updates to be applied out of order. The 
collision detection senses this and the collisions can be 
automatically resolved. 

' In a preferred embodiment, collision detection consists 
of comparing current audit fields of an incoming trade with 
the previous audit fields of the trade database. If the two 
audit fields do not match, a collision is detected. A 
collision is held in a collision queue 557 until it is 
resolved (as described below) . 

In a preferred embodiment, the inbound trade activity 
processor 520 may attempt to resolve a collision by performing 
the following steps after each inbound trade is successfully 
processed. The inbound trade activity processor 520 looks in 
the collision queue 557 for a trade, that has a system number 
and current audit fields that match the system number and 
previous audit fields of the trade that was just successfully 
processed. If found, the trade activity is processed into the 
trades database to resolve the collision. Multiple collisions 
are resolved by repetitively applying the comparison logic and 
processing matches until all of the collisions have been 
resolved . 

In a first alternate embodiment, collisions may be 
prevented by not allowing predetermined trade activity 
functions to operate on a trade activity except for one owning 
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node. This embodiment eliminates collisions because functions 

that may cause collisions are never shared across nodes. 

In a second alternate embodiment, a trade activity 
function will only be processed if the record is in synch with 
what/is termed the financial trading network approved Version. 
The financial trading network approved version will be locked 
when a change is being made in a node. The change made by the 
locking node will then become the financial trading network 
approved version. 

Fig. 9 shows a flowchart 900 of the present invention 
illustrating a trade activity message transmitting process. 
(As discussed above in connection with Fig. 5 and Fig. 8, the 
same process described is applied to static local data in 
trade messages.) In step 910, the method determines whether a 
signal for generating an outbound trade activity message has 
been received. As discussed in conjunction with Fig. 5, the 
signal may be~ generated due to several different occurrences 
and by different sources. A message generation signal may be 
due to a manual input by an operator, due to local trading 
activity, due to an internal condition such as a need for 
information from another node, or an ownership transfer need. 
Therefore, if a signal is received, the method proceeds to 
step 920, else it branches to step 980. 

In step 920, a trade activity is obtained from the trades 
database 547. In addition, other information may be 
incorporated into the outbound trade activity message, such 
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as, for example, the node identifier and the ownership status 

of the trade activity. 

In step 930, the location of a target node or nodes is 
retrieved from the nodes location database 556. 

/ In step 940, the trade activity is inserted into a 
financial trading network communications header to form a 
trade activity message. 

In step 950, the trade activity message and the financial 
trading network communications header are further inserted 
into one or more network communications headers. As 
previously discussed in conjunction with Fig. 5, various type 
communications headers may be used as appropriate. Although 
this is shown as a step in the outbound process, it should be 
understood that addition of network communications headers is 
automatically performed by a network communications handler. 
In the present invention, this may be accomplished by the 
network interface 508 or alternatively by a separate 
hardware/software combination external to the financial 
trading network node 500 . 

In step 960, the trade activity message or the trade 
activity information within the trade activity message may be 
stored in the checkpoint file 536. This information is a 
record of the most recent transaction, and is stored for 
system startup or crash recovery. 

In step 970, the outbound trade activity message created 
in steps 920-950 is transmitted over the network 503 to all of 
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the other subscribing financial trading network nodes defined 
in node location database 556 (Fig. 5). 

In step 980, the method determines whether an 
acknowledgment message has-been received from the other nodes. 
If so, then step 990 updates the message activity log 514 
(Fig. 5), else it branches back to -step 910. 

Fig. 10 shows a flowchart 1000 of the present invention 
illustrating an ownership transfer method of the financial 
trading network. The flowchart 1000 may be viewed in 
conjunction with the ownership transfer protocol diagram of 
Fig. 6. 

In step 1010, a requester node sends an ownership 
transfer request message to an owning node ( i.e, f the node 
that owns the desired trade activity) . 

In step 1020, the method determines whether the ownership 
transfer request message was received by the owning node. If 
it was received, the method branches to step 1030, else it 
branches to step 1060. 

In step 1030, the method determines whether the ownership 
transfer request can be granted. If ownership can be 
transferred, the method proceeds to step 1050, else the method 
branches to step 1040. 

In step 1050, the owning node sends an ownership granted 
message to the requester node. The ownership granted message 
transfers the ownership of a trade activity from the owning 
node to the requester node. 
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In step 1040, the owning node sends an ownership denied 

message to the requester node. The ownership denied message 
prevents the requestor node from changing the trade. 

In step 1060, the method, in the case of a failure to 
receive the ownership transfer request message, determines if 
the failure is due to a crash by the owning node. If a crash 
has occurred, the method proceeds to step 1070, else it 
branches to step 1080. 

In step 1070, the ownership transfer request message is 
re-delivered to the owning node. This may be done by the 
network interface 508. After step 1070, the method branches 
back to step 1020. 

In step 1080, a new ownership transfer request message is 
sent by the requester node to the owning node. This may be 
performed by a human operator in conjunction with the network 
monitor 511. After step 1080, the method branches back to 
step 1020. 

While the invention has been described in detail above, 
the invention is not intended to be limited to the specific 
embodiments as described. It is evident that those skilled in 
the art may now make numerous uses and modifications of and 
departures from the specific embodiments described herein 
without departing from the inventive concepts. 
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What is claimed is: 

1. A computer network node for a financial trading 
network, comprising : 

a database capable of- storing trade data; 
/a network interface for connecting said network node to a 
computer network over which a trade message may be transmitted 
or received; 

a unique node identifier for said network node; 

an inbound trade processor connected to said network 
interface, with said inbound trade processor capable of 
receiving an inbound trade message and capable of extracting 
inbound trade data included in said trade message; 

an outbound trade processor connected to said network 
interface, with said outbound trade processor capable of 
creating an outbound trade message, and capable of inserting a 
trade message into an appropriate network communications 
protocol including a financial trading network communications 
protocol and said node identifier and communicating said 
outbound trade message to said network interface; 

a database processor for controlling outputs from said 
database and capable of creating and sending an outbound trade 
message to said outbound trade processor; 

a background processor connected to said database, and 
connected to said network interface, being capable of sending 
and receiving an ownership transfer message and reconciling 
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said ownership transfer message 
contained in said database. 



with 



an 
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ownership status 



2. The network node* of claim 1, wherein a network 
monitor is connected to said network and capable of obtaining 
and displaying information on a status of similar nodes on 
said financial trading network; 

3. The network node of claim 2, wherein said network 
monitor further includes a message activity log for logging an 
inbound or an outbound trade message. 

4. The network node of claim 1, wherein said financial 
trading network protocol comprises: 

a message header comprising a message length data, a 
message type data, a data buffer length data, and an 
acknowledge buffer length data; and 

a message body comprising a trade data buffer and an 
acknowledge buffer . 

5. The network node of claim 4, wherein a network node 
that is not a financial trading network node can communicate 
with said network node using said financial trading network 
protocol . 
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6, The network node of claim 4, wherein said financial 

trading network protocol can be nested in a general network 
protocol . 

/7 . *The network node of claim 4, wherein said financial 
trading network protocol can be nested in a general network 
protocol . 

8. The network node of claim 1 , wherein said network 
node sends an acknowledgment message in response to a 
successful receipt of said inbound trade message. 

9. The network node of claim 1, wherein said database 
further contains a nodes location database. 

10. The network node of claim 1, wherein said database 
further contains a trades ownership database. 

11. The network node of claim 1, wherein said network 
node further includes a checkpoint file connected to said 
outbound trade processor, with said checkpoint file being 
capable of storing trade information about a last successfull 
processed deal by said outbound trade processor. 
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12. The network node of claim 11, wherein said trade 

information contained in said checkpoint file can be used 
during startup of said network node. 

13. The network node of claim 11, wherein said trade 
information contained in said checkpoint file can be used for 
crash recovery. 

14. The network node of claim 1, wherein said background 
processor is further capable of comparing an ownership status 
of an inbound trade message and. an ownership status contained 
in said database and thereupon transmitting an ownership 
transfer message over said network if said inbound trade 
message and said database contain different ownerships. 

15. The network node of claim 1, wherein said trade 
message comprises common data fields, product specific data 
fields, rnacro specific data fields, settlement instruction 
data fields, and audit data fields. 



16. The network node of 
message comprises both active 
static local data fields. 

17. The network node of 
message includes active trade 



claim 1, wherein said trade 
trade activity data fields and 

claim 1, wherein said trade 
activity data, said inbound 
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trade message includes inbound active trade activity data, 

said database is a trades database, and said outbound trade 
message includes outbound active trade activity data. 

.'18. The network node of claim 1, which includes £ first 
database capable of storing active- trade activity data and a 
second database capable of storing static local data, and 
wherein said trade messages include both active trade activity 
data and static local data, and wherein said database 
processor is capable of controlling outputs from said first 
and second databases; and said background processor is 
connected to said first and second databases and is capable of 
sending and receiving an ownership transfer message and 
reconciling said ownership transfer message with an ownership 
status contained in said first database. 

19. A financial trading network node process for 
receiving inbound trade messages over a computer network, 
comprising the steps of: 

receiving an inbound trade message over a network at a 
first node; 

removing a financial trading network communications 
protocol from said inbound trade message; 

storing a trade activity contained in said inbound trade 
activity message in a database; and 
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sending an acknowledge message corresponding to receipt 

of said inbound trade message. 



20. The financial trading network node process of claim 
19, -""wherein each said financial trading network node has a 
unique identifier. 

21. The financial trading network node process of claim 
19, wherein collisions between messages on said financial 
trading network are detected. 

22. The financial trading network node process of claim 

21, wherein a financial trading network node adds to a 
collision resolution queue of said inbound trade message if a 
collision is detected. 

23. The financial trading network node process of claim 

22, wherein the adds to said collision resolution queue are 
checked after every trade message is processed, and any 
collisions for said trade message are then resolved. 



24. A financial trading 
generating outbound financial 
network, comprising the steps 



network node process for 
trade messages over a computer 
of: 
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1 receiving in a first financial trading network node a 

2 signal to transmit a trade message to a second financial 

3 trading network node; 

\ creating a trade message by obtaining trade data from a 



s database in said first financial trading network node;* 

i retrieving a target node location or locations from a 

7 nodes location database and placing said target node location 

; or locations in said trade message; 

> inserting said trade message into a financial trading 

i network communications protocol; 

inserting said trade message and said financial trading 

network communications protocol into a network communications 

protocol ; 

transmitting a message including said trade message, said 
financial trading network communications protocol, and said 
network communications protocol over said computer network, 
and receiving in a first financial trading network node an 
acknowledgment message . 

25. The financial trading network node process of claim 
24, wherein during the transmitting step the outbound trade 
message is stored in a message activity log file and the 
message activity log is updated with the acknowledgment 
message . 
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26. The financial trading network node process of claim 

24, wherein during the transmitting step the latest trade 
message is stored in a checkpoint file. 

-"" 27. The financial trading network node process of claim 
24, wherein said checkpoint file may be used for startup of 
said financial trading network node. 

28. The financial trading network node process of claim 
24, wherein said checkpoint file may be used for crash 
recovery of said financial trading network node. 

29. The financial trading network node process of claim 
24, wherein said signal of said receiving step is an event 
flag. 

30. The financial trading network node process of claim 
24, wher'ein each said financial trading network node has a 
unique identifier . 

31. The financial trading network node process of claim 
24, wherein an operator can manually resend an outbound 
financial trade message. 
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32. The financial trading network node process of claim 

24, wherein trade ownership can only be changed by a node that, 
owns said trade ownership . 

/ 33. The financial trading network node process o x f claim 

24, wherein a message activity log file containing copies of 

all outbound trade messages can be used to monitor financial 
trading network message traffic. 



34 . The financial trading network node process of claim 
24, which includes trade ownership status transactions and 
wherein said ownership status transactions are serialized to 
facilitate ownership resolution when multiple transactions 
occur for a trade. 

35. The financial trading network node process of claim 
24, wherein said signal to transmit a trade message is a 
signal t'o transmit the trade message to all other nodes in the 
financial trading network, and wherein the transmitting step 
transmits the message to all of said other nodes, and wherein 
the acknowledgment message received in the first financial 
trading network node is received from all other financial 
trading network nodes. 



36. An ownership transfer process for a financial 
trading network, comprising the steps of: 
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sending an ownership transfer request message from a 

requestor node to an owning node; 

determining if the ownership transfer request message 
from the requestor node was received by the owning node; 

if the ownership transfer request message was received by 
the owning node, determining whether the request can be 
granted and sending an ownership granted message to the 
requestor node if the request can be granted, and sending an 
ownership denied message to the requestor node if the request 
cannot be granted; 

if said ownership transfer request message was not 
received by said owning node, determining if said owning node 
crashed; 

re-delivering said ownership transfer request message to 
said owning node if said ' ownership transfer was not received 
by said owning node and said owning node had crashed; 

manually resending said ownership transfer request 
message 'if said ownership transfer was not received by said 
owning node and said owning node did not crash; and 

sending a second ownership transfer message from said 
owning node to said requester node if a second ownership 
transfer request message is received by said owning node 
before said ownership transfer message is sent by said owning 
node . 
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1 37. The ownership transfer process of claim 36, wherein 

2 said re-delivering step is performed by a network interface. 

1 38. The ownership transfer process of claim 36, wherein 

2 said manually resending step is performed by a human operator. 
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